1. Field of the Invention
The present invention relates generally to a syntax for networking identifier decorations, and more particularly, to a method and apparatus for the production and use of decorated networking identifiers.
2. Description of the Related Art
An Access Point Name (APN) is a networking identifier that is used to identify a particular network service, such as, for example, the Internet or a private network. A client terminal, or a User Equipment (UE), supplies the APN when connecting to a network and obtaining specific resources for the connection. The network associated with the APN is usually described as a Packet Data Network (PDN).
The general form of an APN, as provided in Third Generation Partnership Project (3GPP) TS 23.003, is:                <APN Network Identifier>“.”<APN Operator Identifier>The network identifier is shown first, and the operator identifier is a Domain Name System (DNS) name corresponding to an operator. Before 3GPP release 8, the two parts together corresponded to the DNS name of a Gateway General Packet Radio Service (GPRS) Support Node (GGSN).        
The APN, in the form of a well-structured DNS name (see, for example, RFC 1035, RFC 1123, RFC 2181), has additional constraints. The APN has a maximum length of 100 octets, and the APN consists of one or more labels. The network identifier does not start with the strings “rac”, “lac”, “sgsn”, “mc”, nor end in “.gprs”, nor take the value “*”. The operator identifier takes the form “mnc<MNC>.mcc<MCC>.gprs” (although .gprs may change in the future).
The APN is used to identify a particular network that the client terminal wishes to access, and which is offered by an operator. The operator is typically a home operator of the client terminal; however, it may also be a visited operator in the case of local breakout scenarios. It is possible to omit the operator identifier from the general form of the APN. In such a scenario, the DNS in the Public Land Mobile Network (PLMN) translates the APN network identifier into the ‘default’ GGSN for the network identifier provided.
In the past, an APN directly identified an association between the client terminal and a PDN. The client terminal could attach to multiple PDNs (using different APNs), but was only allowed one connection to each PDN. In the 3GPP System Architecture Evolution (SAE) architecture for the enhanced packet core, it is possible for the client terminal to attach to the same PDN more than once, for example, to support a client terminal with multiple addresses. This characteristic is useful in supporting a ‘split terminal’ by means of an integrated terminal. For example, a laptop could make use of the Long Term Evolution (LTE) connection obtained by means of a cell phone.
However, a problem exists with respect to a multiple PDN connection from the same terminal to the same PDN, in that it is not possible for the client terminal to identify an individual connection by means of the APN alone. It is necessary for the client terminal to identify these connections in order to terminate them. It has been suggested that a form of decoration be used on the APN, so that the APN (first, second, third, etc.) may be identified. The suggested syntax, using Augmented Backus-Naur Form (ABNF), as described in RFC 4234, is:    APN=1*label    label=; A DNS label, as described in RFC 1035    index-decorated-APN=APN “;” index    index=DIGIT
; An ‘index’ indicates a PDN connection in the case
; that a terminal has more than one PDN connection
; to the same PDN identified by the APN string.
For example, the decorated APN “Internet.mnc012.mcc345.gprs;1” would identify a first connection, while the decorated APN “Internet.mnc012.mcc345.gprs;2” would identify a second connection.
APN decoration has not yet been formally defined in 3GPP specifications. It must be specified that the decoration be removed before processing, and used for other purposes. The only existing proposal to decorate APNs is for the purpose of identifying and distinguishing PDNs; however, the need for additional extensions are likely in the future, since these extensions provide one of the easiest ways for the client terminal to signal information to the core network.
A fundamental problem with the suggested APN decoration scheme is that it will not be compatible with future decorations, in that future decoration schemes will require a revision of the previous standard. It will be very difficult to provide additional decorations to the APN since parsers will expect only an APN or an index-decorated-APN. This means that a new decoration applied to an APN in the future will be incompatible with existing parsers built for APNs or index-decorated-APNs.
In determining standards for decorating the APN, the following constraints must be considered. The basic syntax of the APN string is defined in 3GPP TS 23.003, and the syntax of the elements of the APN string is defined by RFC 1035. The syntax of the decorations is not yet constrained as there are no examples yet standardized. The size of the APN limited to 100 bytes. The basic structure of the APN must not be obscured or difficult to recover.
A Network Access Identifier (NAI) is a second type of networking identifier, specifically an Internet Engineering Task Force (IETF) standard identifier that is used in initiating, authenticating, and authorizing network access required for applications, such as a Virtual Private Network (VPN), Voice over Internet Protocol (VoIP), Fourth Generation (4G) mobile communications, dial-up access, etc. The NAI includes the user identity information and the operator information, in a form similar to that of an email address: Identity@Operator. The NAI syntax is:
nai = username / (username “@” realm)username = dot-stringdot-string = string / (dot-string) “.” stringstring = char / (string char)char = c / (“\” x)c = < any 128 ASCII characters except special or SP >x = %x00-7F    ; All 127 ASCII characters, no exceptionSP = %x20    ; Space characterspecial = ; a list of reserved characters; this list does not include “#”, “.”. “|” or “~”
Many applications require information before authentication and authorization procedures may commence; however, there exists only two ways to insert this information. First, the information may be included in an extension, or decoration, of the NAI. Second, the information may be included through specialization of the authorization and authentication procedure. NAI decoration is easier to define and standardize than specialized authorization and authentication procedures. A decorated NAI may take the form of: {ip=12.34.56.78}joe@example.com
Applications require a software stack (multiple layers), where each layer may require a decoration. Thus, multiple NAI decorations conflict, which complicates standardization. There is no general way to allow for arbitrary decoration that guarantees conflicts do not arise.
In determining standards for NAI decorations, the existing syntax and size of NAI should be considered. Further, the decorations must not obscure the NAI.